1. Field of the Invention
The present invention generally relates to the field of telecommunications. More particularly, the present invention relates to a user interface, such as a personal computer (PC) interface, for accessing and maintaining profile data of a user's subscribed telephony service.
2. Acronyms
The written description provided herein contains acronyms which refer to various telecommunications services, components and techniques, as well as features relating to the present invention. Although some of these acronyms are known, use of these acronyms is not strictly standardized in the art. For purposes of the written description herein, acronyms will be defined as follows:                Advanced Intelligent Network (AIN)        Computer Access Restriction (CAR)        Common Channel Signaling (CCS)        Central Office (CO)        Calling Party Number (CPN)        Call Processing Record (CPR)        Data and Reporting System (DRS)        Integrated Service Control Point (ISCP)        Interactive Voice Response (IVR)        Local Area Network (LAN)        Personal Computer (PC)        Positive ID (PID)        Private Branch Exchange (PBX)        Service Creation Environment (SCE)        Service Control Point (SCP)        Service Order Assignment Control (SOAC)        Service Management System (SMS)        Service Provisioning And Creation Environment (SPACE)        Service Switching Point (SSP)        Signaling Transfer Point (STP)        Transaction Capabilities Applications Part (TCAP)        Transmission Control Protocol/Internet Protocol (TCP/IP)        User Interface (UI)        Wide Area Network (WAN)        Working Telephone Number (WIN)        
3. Background Information
In recent years, a number of new telephony service features have been implemented and provided by an Advanced Intelligent Network (AIN). The AIN evolved out of a need to increase the capabilities of the existing telephone network architecture and meet the growing needs of telephony customers. The AIN architecture generally comprises two networks, a data messaging network and a trunked communications network. The trunked communications network handles voice and data communications between dispersed network locations, whereas the data messaging network is provided for controlling operations of the trunked communications network.
An illustration of the basic components of an AIN network environment is shown in FIG. 1. The AIN network is provided to facilitate communication between a plurality of network locations or stations 72-86. As shown in FIG. 1, central offices (COs) 64-71 are provided for sending and receiving data messages from a service control point (SCP) 56 via one or more signaling transfer points (STPs) 51, 53 and 59. The data messages are communicated to and from the COs 64-71 and the SCP 56 along a common channel signaling (CCS) network 88. Each CO 64-71 serves as a network service switching point (SSP) and may be equipped with CCS capabilities, which provides for the two-way communication of data messages between each SSP and the SCP 56 via CCS network 88. These data messages may be formatted in accordance with Transaction Capabilities Applications Protocol (TCAP).
Each CO 64-71 serving as a network SSP routes AIN-service related telephone calls between a calling station (e.g., station 72) and a called station (e.g., station 84) based on instructions received from the SCP 56. The SSPs 64-71 may be connected by trunked communication lines 90 to transport voice and/or data signals. Each of the stations 72-86 is connected to one or more SSPs 64-71 through private or dedicated telephone lines 93. In AIN-type call processing, the originating SSP is responsible for: identifying calls associated with AIN services; detecting when conditions for AIN service involvement are met; formulating service requests or queries to the SCP 56 for call processing instructions; and responding to the instructions or message responses received from the SCP 56 to complete or terminate the call.
In FIG. 1, the SCP 56 is implemented as part of an integrated service control point (ISCP) 10. The ISCP 10 is an integrated system which may include a programmable SCP 56 and a data and reporting system (DRS) 28. The SCP 56 executes software or programmed-based logic, in accordance with a subscriber's call processing record (CPR), and returns call routing instructions to the SSPs. The DRS 28 compiles calling information to be used for billing and administrative purposes. A service creation environment (SCE) (not shown) may also be provided for programming and provisioning the CPRs stored in the database of the SCP 56. The CPRs define the services for each individual subscriber. The SCE may be integrated with the ISCP 10 or provided as a separate application or entity. By way of a non-limiting example, the ISCP 10 may be implemented with a Bellcore integrated service control point (ISCP) available from Bell Communications Research (Bellcore), Murray Hill, N.J., and the SCE may be implemented with SPACE, which is also available from Bellcore. SPACE is a service provisioning and creation environment. SPACE stores a copy of the data in the ISCP and is the network element used for data queries and management by the selected users which have access to it. The users do not access the ISCP directly because direct access would interfere with call processing by performing data manipulations on the same platform. Updates made through SPACE are input into the ISCP immediately. The service order assignment control (SOAC) system receives all service order activity from service personnel and forwards the service orders to the SMS.
For additional information regarding AIN and AIN-related network environments, see Berman, Roger K., and Brewster, John H., “Perspectives on the AIN Architecture,” IEEE. Communications Magazine, February 1992, pp. 27-32, the disclosure of which is expressly incorporated herein by reference in its entirety.
A number of services have been provided by AIN or AIN-type intelligent networks to provide specialized call processing of incoming calls and detailed call information. Services such as call routing, call forwarding and call logging have been provided by AIN or AIN-type networks. Service activation of a particular AIN service is normally accomplished by service personnel who receive a service order from a customer, and then provision or create the CPR that is unique for each working telephone number (WTN) in the SCP or ISCP. Each customer's CPR contains subscriber or profile data which control and/or define the service features and parameters associated with the AIN service subscribed to by the customer. Modification to a customer's CPR may be performed by service personnel based on requests received from the customer (e.g., by a formal written submission for service modification or via telephone interaction with service personnel). For more “simple” AIN services (i.e., AIN services that are based on very few or limited service parameters), automated modification systems and methods have also been provided to permit a customer or user to modify their service profile data via a telephone connection and touch tone dialing or Dual Tone Multi Frequency (DTMF) response.
An example of such a simple AIN service is selective call acceptance which was deployed in Wichita, Kans. in 1994. Selective call acceptance allows residential and small business customers to provide a screening list of 50 authorized telephone numbers and one access code in order to allow people calling from one of the authorized numbers or with the access code to connect to the subscriber's working telephone number. If an unauthorized caller calls the subscriber's working telephone number, the unauthorized caller can be routed to an alternative location if desired, for example, a voice mailbox. When the subscriber chooses to modify the authorized numbers and/or access code, the subscriber either contacts service personnel or modifies their service profile data via DTMF.
While such prior systems have been provided, the ability for a customer to freely access and maintain their service profile data has been limited. Prior attempts have relied upon the involvement of service personnel or have limited a customers ability to access and modify their service profile data. DTMF-based interfaces have also not provided an efficient or user-friendly system by which customers may review and revise their service profile data. Further, for more “complex” AIN-based services (i.e., AIN services based on a large number of service parameters or including more complex sets or groups of service parameters) such prior attempts have not provided an effective solution for automated service management and maintenance. Thus, there is currently a need for an interface permitting users to freely access and maintain their service profile data. A need also exists for a user interface permitting a user to review and update their data for services, such as AIN-based services, through a computer-based interface without requiring the involvement of or interaction with service personnel.